feat(qt): create and top up the DashPay identity - #7765

…ehind PLATFORM_GUI=1

bfe078a ci: build linux64 against depends with PLATFORM_GUI=1 (pasta)
2525537 build: add --enable-platform-gui (pasta)
3a4de8a build(depends): build dash-sdk-cxx behind a PLATFORM_GUI knob (pasta)
30f071c build(depends): add a prebuilt Rust toolchain and per-host standard library (pasta)

Pull request description:

  ## Issue being fixed or feature implemented

  The Dash Platform GUI (DPNS usernames, DashPay profiles, contacts and contact payments) links a Rust library: `dash-sdk-cxx`, from `packages/rs-sdk-cxx` in dashpay/platform (dashpay/platform#4633). It is a thin cxx binding of `dash-sdk`, which handles transport, proof verification and state-transition assembly. Core keeps the keys, the trust inputs and the UI. This PR is only the build foundation: depends can build the binding behind `PLATFORM_GUI=1`, and `configure --enable-platform-gui` can link it. Nothing in `src/` uses it yet. #7512 has the full map of the stack.

  ## Decision requested

  Before reviewing the code, maintainers need to answer one question: **should depends carry a prebuilt, sha256-pinned Rust toolchain and a prebuilt protoc, built only when `PLATFORM_GUI=1` is set?** If the answer is no, this PR closes, and the stacked client and GUI PRs (#7670, #7671, #7765, #7766, #7767) need a different design. The wallet seams in #7763 are useful either way.

  **What depends would carry (only with `PLATFORM_GUI=1`)**

  | Package | What | Pinned by |
  |---|---|---|
  | `native_rust` | prebuilt `rustc` and `cargo` 1.98.1 (the toolchain dashpay/platform pins), from the component `.tar.xz` archives, for the four build hosts depends supports | sha256 of each static.rust-lang.org archive |
  | `rust_stdlib` | prebuilt Rust standard library for the host, and for the build machine when it differs; every Linux host uses the glibc (`-unknown-linux-gnu`) one | sha256 per host |
  | `native_protobuf` | prebuilt `protoc` 32.0, which build scripts in the crate closure (such as tenderdash-proto's) use to generate protobuf code | sha256 per build host |
  | `platform_cxx` | `dash-sdk-cxx` (`libdash_sdk_cxx.a`, headers `dash/sdk/*.h`), built `--frozen --offline` from a Platform source tarball and a crate bundle, both at one Platform commit | commit plus two sha256s |

  **Costs**
  - Download: the Rust toolchain's rustc and cargo components are 57 MB to 91 MB per build architecture (91 MB for x86_64 Linux), plus 26 MB to 30 MB of standard library per host (and for the build machine when it is a different target). The Platform tarball is 158 MB and the crate bundle 63 MB.
  - Mirror: every pin bump adds those two Platform archives to the depends sources mirror. The bundle has no upstream URL, and GitHub does not promise stable bytes for its archive endpoint.
  - CI: one more depends job (`x86_64-pc-linux-gnu_platform_gui`). The `linux64` job builds against it instead of the shared `x86_64-pc-linux-gnu` depends, which `linux64_asan` and `linux64_fuzz` keep, so there is no extra build or test job.
  - Maintenance: whoever bumps the pin runs `contrib/devtools/platform-bundle.sh <commit>`, which prints the new pins and reproduces the bundle hash, and uploads both archives. `contrib/devtools/update-rust-hashes.py` refreshes the toolchain pins.

  **Precedents**
  - Zcash carries a prebuilt Rust toolchain in its depends. `native_rust.mk`, `rust_stdlib.mk` and `update-rust-hashes.py` are derived from Zcash's.
  - libmultiprocess is an external library that depends pins by commit.
  - `PLATFORM_GUI` copies the `MULTIPROCESS` knob, which is the approach requested on #7109.

  **Default builds are unchanged.** Without `PLATFORM_GUI=1`, depends builds the same package set as develop for every host, and config.site leaves `--enable-platform-gui` off. With it, config.site sets the option to `auto`, which configure keeps on only when the GUI and the wallet are built, so `--enable-fuzz`, `--without-gui` and `--disable-wallet` still configure against those depends. With the option, only `dash-qt`, `test_dash` and `test_dash-qt` link `dash-sdk-cxx`, so `dashd`, `dash-cli`, `dash-tx`, `dash-util`, `dash-wallet`, `bench_dash` and the fuzz binary never link Rust on any OS. CI enforces this: `linux64` builds with the option, and `contrib/devtools/check-no-rust.py` then fails that job if any of those seven binaries contains Rust or cxx-bridge symbols, or has no symbols to check.

  **It is an opt-in developer build, not a release one.** With `PLATFORM_GUI=1` inside a Guix environment, depends stops with an error, so release binaries are built without it. The remaining Guix work: Guix's own Rust versus the prebuilt one, the mingw-w64 `dlltool`, a two-builder hash match, ring and blst on armhf, ppc64 and riscv64, and a per-binary Windows DLL allowlist for `dash-qt`. `depends/README.md` and `doc/dependencies.md` say this, and that CI builds and tests it on x86_64 Linux only.

  ## Merge gates

  1. **Policy (maintainers).** The decision above. A maintainer approved this PR on 2026-10-21, at the previous pin. The head has changed since (the docs, the two host fixes below, and the rebase onto develop with the CI job move), so it needs a fresh review.
  2. **Platform merge. Done.** dashpay/platform#5473 (makes the workspace lockfile vendorable) merged on 2026-10-29, and dashpay/platform#4633 merged on 2026-11-02 into the protected `v5.1-dev` branch. This PR pins that merge commit, `fb463c282ea09adf93dd5d256fc9471969f7a46f`.
  3. **Mirror upload. Done (2026-11-02).** Both archives are on the depends sources mirror, and each returns 200 with the pinned sha256:
     - `platform-fb463c282ea09adf93dd5d256fc9471969f7a46f.tar.gz`, sha256 `8ccb913069ce8d96a32443e98e44e85c331694727cc37c321364711ddaa04039`
     - `dash-sdk-cxx-crates-fb463c282ea09adf93dd5d256fc9471969f7a46f.tar.gz`, sha256 `da47a0ca89ed023f357a70e19d097f42bd4fe76221ee7bfd1c4eca0102b5f70e`
  4. **CI. Done on the fork.** This PR's dashpay CI runs develop's workflows (`pull_request_target`), which have no Platform GUI job, so a green PR run says nothing about the CI commit. The branch's own workflows ran in a fork `push` run against the real mirror (see below).

  ## What was done?

  **depends**
  - `native_rust`, `rust_stdlib`, `native_protobuf` and `platform_cxx`, all added only by `PLATFORM_GUI=1`. Combining it with `NO_QT` or `NO_WALLET` is an error.
  - The package is named `platform_cxx`, and the configure variables are named `PLATFORM_CXX_*`, after the `PLATFORM_GUI` feature's C++ binding rather than after the crate. The stacked PRs consume those variables, and the crate name appears only where it is the artifact: `-p dash-sdk-cxx`, `libdash_sdk_cxx.a`, `dash_sdk_cxx.pc` and `dash-sdk-cxx-crates-<commit>.tar.gz`.
  - `platform_cxx` builds only from the two sha256-pinned archives. Cargo runs with `--frozen --offline` and never touches the network. tenderdash-proto's sources come from a Tenderdash archive inside the bundle, next to the `TENDERDASH_COMMITISH` that names it.
  - Isolation: only the bundle's Cargo configuration is used. Cargo runs from `/` with `--config`, and its home is private. Variables that would change the build (wrappers, `CARGO_BUILD_*`, `CARGO_PROFILE_*`, `CARGO_TARGET_*`, every variable named after the host's or the build machine's Rust triple in either spelling, such as `CC_x86_64-unknown-linux-gnu` or `CFLAGS_x86_64_unknown_linux_gnu`, the generic `CC`/`CFLAGS`/`AR`/`RANLIB` and `HOST_*`/`TARGET_*` fallbacks cc-rs reads, `TENDERDASH_*`) are unset. The depends compilers and flags are then set in Cargo's own environment, after those removals. The release profile is pinned to Platform's (`panic = "unwind"`).
  - The depends host compiler links the crate and compiles its C and C++. The depends build compiler links build scripts and proc macros. The build directory is remapped out of the objects.
  - The build fails if the dependency graph (`cargo tree -e normal,build`, matched by exact crate name) reaches the trusted context provider, a general-purpose HTTP client (reqwest, isahc, attohttpc, surf, curl) or a system TLS library (openssl, native-tls, hyper-tls). ureq is allowed: it is only `tenderdash-proto-compiler`'s archive downloader, which never runs, because the bundle carries the archive and Cargo is offline.
  - **System libraries.** `platform_cxx.mk` holds a vetted per-OS list of the system libraries the archive needs. rustc prints its own list (`--print=native-static-libs`), and the build fails if that list has a library that is neither vetted nor in an explicit, commented ignore set. For example, glibc's `-lutil` and `-lrt` are ignored, because `symbol-check.py` does not allow them and the standard library imports nothing from them. The vetted list goes to configure through an installed `dash_sdk_cxx.pc`. The Linux and macOS lists are within `symbol-check.py`'s allowed libraries; the mingw-w64 one is not (`ntdll.dll`, and the DLLs raw-dylib imports add, which rustc never reports), and the comment says so. Guix refuses `PLATFORM_GUI`, so `symbol-check.py` never sees these builds.
  - **mingw-w64:** rustc also reports `-lwindows.0.52.0`, the import library windows-targets 0.52 bundles (socket2 0.5, through hyper-util). It is in the ignore set: every function it names is in the vetted mingw-w64 import libraries, and the `dash-qt` link fails loudly if a later pin needs one that is not.
  - **powerpc64-linux-gnu:** `PLATFORM_GUI` is refused before anything is fetched. Rust links linux-gnu targets with its bundled rust-lld, which rejects big-endian POWER's ELFv1 objects, and the options to use the depends linker instead are unstable there. `depends/README.md` names it, and the hosts `rust_stdlib.mk` has no entry for (such as `powerpc64le-linux-gnu`), as unavailable.
  - **Docs:** `depends/README.md` and `doc/dependencies.md` describe it as an opt-in developer build: Guix refuses it, release binaries are built without it, CI builds and tests it on x86_64 Linux only, and Rust and protoc are pinned prebuilt binaries verified by SHA256.
  - `contrib/devtools/platform-bundle.sh <commit>` produces the crate bundle reproducibly and prints the pins.
  - `contrib/devtools/update-rust-hashes.py` refreshes the toolchain pins, checking each download against the `.sha256` file published next to it.

  **configure:** `--enable-platform-gui` (default no) requires the GUI and the wallet. The `auto` that PLATFORM_GUI depends set becomes `no` without them, with a notice. It takes `PLATFORM_CXX_CFLAGS` and `PLATFORM_CXX_LIBS` from `dash_sdk_cxx.pc` through `PKG_CHECK_MODULES`, and both can be overridden as usual. It then link-tests creating and shutting down a `dash_sdk::PlatformClient` (`#include <dash/sdk/ffi.h>`). `PLATFORM_CXX_LIBS` is added to the link of `dash-qt`, `test_dash` and `test_dash-qt` only.

  **CI**
  - A `linux64_platform_gui` depends job builds with `PLATFORM_GUI=1`, and `linux64` builds against it instead of the shared `x86_64-pc-linux-gnu` depends, as `linux64_tsan` builds against `linux64_multiprocess`'s. #8058 removed `linux64_sqlite`, which this PR used before; `linux64` is the only x86_64 job left with the wallet and GUI and no sanitizers. `linux64_asan` and `linux64_fuzz` keep the plain depends. The new depends job is in the fast tier, with the `linux64` build it feeds.
  - `linux64` then runs `check-no-rust.py` on the seven binaries. Its other checks are unchanged and now cover the option: `test_dash` (which links `dash-sdk-cxx`), `check-stdlib-paths` and the previous-releases functional tests. It does not run `test_dash-qt`; this PR adds no Qt tests.
  - The new depends job's cache check runs on x86_64, like its build. Pull request CI runs develop's workflows with the pull request's own `ci/` scripts, so a pull request based before this one has no matrix entry for `linux64_platform_gui` and guesses its host from the machine. On the ARM runner the other depends jobs check on, that host would not match the build runner's and the pull request would lose `linux64` until rebased; on x86_64 it builds the plain depends, as before.
  - "Cache depends sources" also downloads the x86_64 Linux Platform GUI sources: the toolchain, protoc, standard library and Platform archives. It names the build machine, because its runner may be ARM. Its cache key is unchanged; it hashes `depends/packages/*`, which the new packages change.

  Pinned: dashpay/platform `fb463c282ea09adf93dd5d256fc9471969f7a46f` (`packages/rs-sdk-cxx`, crate `dash-sdk-cxx`), with the tarball and crate bundle listed under merge gate 3.

  ## How Has This Been Tested?

  Environment-scrub revision (head `bfe078a835a7`, same base and pin; only `build(depends): build dash-sdk-cxx…` changes, the other three commits are identical):
  - Per-target variables were injected in both spellings for both triples (for example `CFLAGS_x86_64_unknown_linux_gnu=-Werror=bogus`, `ARFLAGS_aarch64_unknown_linux_gnu=--bogus`, `CXXSTDLIB_x86_64_unknown_linux_gnu=c++`). The environment Cargo receives no longer contains any of them, natively and for `HOST=aarch64-linux-gnu`; at parse time this also holds for mingw-w64 and x86_64 macOS. Without the injected variables, the environment Cargo receives is the same as at `406cf256e5fa`.
  - With those variables injected, `make -C depends PLATFORM_GUI=1` builds `platform_cxx` natively and for `HOST=aarch64-linux-gnu`. Both report the same `native-static-libs` as a clean build (`-lstdc++ -lgcc_s -lutil -lrt -lpthread -lm -ldl -lc`), and ring's build script sees no injected build-machine `CFLAGS`. At `406cf256e5fa` the same aarch64 build fails: blake3 on the injected `ARFLAGS`, then ring on the injected build-machine `CFLAGS`.
  - Fork `push` run [42869942430](https://github.com/PastaPastaPasta/dash/actions/runs/42869942430) at `bfe078a835a7`: every job passed. All 48 PR checks passed too. Three of them (the x86_64 and aarch64 depends jobs and `mac-build`) first failed when their self-hosted runners lost contact with GitHub mid-build; they passed when rerun.

  Review-fix revision (head `406cf256e5fa`, same base and pin), x86_64 Linux:
  - `make -C depends PLATFORM_GUI=1` builds every package with the new toolchain recipes, including `platform_cxx` (system-library and forbidden-crate checks pass). `update-rust-hashes.py --check` passes for all 16 pins.
  - A reviewer built `rust_stdlib` for `HOST=x86_64-w64-mingw32`, which fetches and stages both standard libraries (the host's and the build machine's).
  - configure against that prefix: the default gives `platform gui = yes` and the link test passes. `--enable-fuzz`, `--without-gui` and `--disable-wallet` each configure with `platform gui = no`. `--without-gui --enable-platform-gui` still stops with "requires the GUI".
  - The forbidden-crate pattern matches nothing in the real `cargo tree` for x86_64 Linux, mingw-w64 or aarch64 macOS, with `CARGO_TERM_UNICODE` true or false. A positive control (`ureq|hyper`) matches.
  - `platform-bundle.sh fb463c28…` (now dropping Platform's `.cargo` before pruning) reproduces the pinned bundle hash `da47a0ca…`.
  - Fork `push` run [42857408117](https://github.com/PastaPastaPasta/dash/actions/runs/42857408117) at `406cf256e5fa`: every job passed, including the `PLATFORM_GUI` depends job and the `linux64` build and tests, except `linux64_multiprocess-lint`. Its runner received a shutdown signal during clang-tidy.

  Earlier revisions:

  Rebased onto develop `4c5c0153500f`, at this pin (`fb463c28`), in an `ubuntu:noble` container on x86_64 Linux, commit by commit in one tree:
  - `build(depends): add a prebuilt Rust toolchain…`: default depends, configure and build pass.
  - `build(depends): build dash-sdk-cxx…`: `make -C depends PLATFORM_GUI=1` builds every package, including `platform_cxx` from the two archives, and stages `libdash_sdk_cxx.a`, `dash/sdk/ffi.h` and `dash_sdk_cxx.pc`. Configure and build pass.
  - `build: add --enable-platform-gui`: from a clean tree, configure with the `linux64` job's flags (`--enable-zmq --with-libs=no --enable-reduce-exports`, `-DDEBUG_LOCKORDER -DDEBUG_LOCKCONTENTION -DBOOST_MULTI_INDEX_ENABLE_SAFE_MODE`, `LDFLAGS=-static-libstdc++`, gcc-14, plus `--enable-external-signer --enable-werror`) and `--enable-platform-gui` reports `platform gui = yes`, and the build passes.
  - `ci: build linux64…`, on that build:
    - `check-no-rust.py` passes for `dashd`, `dash-cli`, `dash-tx`, `dash-util`, `dash-wallet`, `bench_dash` and the fuzz binary.
    - A positive control linked against `libdash_sdk_cxx.a` (create and shut down a `PlatformClient`, as configure's link test does) fails `check-no-rust.py`, which lists its Rust symbols. `dash-qt`, `test_dash` and `test_dash-qt` pass it here: they link the archive, but nothing in this PR calls the binding, so no archive member is pulled in.
    - `make -C src check-stdlib-paths` passes.
    - `make check` passes (156 `test_dash` test files, `test_dash-qt`, univalue, minisketch, secp256k1, bench sanity).
  - Disabled, at the head: default depends (no `dash_sdk_cxx.pc` in the prefix) and default configure (`platform gui = no`) build. `check-no-rust.py` passes for all ten binaries, `dash-qt`, `test_dash` and `test_dash-qt` included, and `make check` passes.
  - Lints: lint-whitespace, lint-files, lint-shell, lint-shell-locale, lint-python-utf8-encoding and lint-tests pass. actionlint reports nothing in `build.yml` beyond develop's own four findings.
  - Fork `push` run [42354400055](https://github.com/PastaPastaPasta/dash/actions/runs/42354400055) at 86902f7 passed every job. The `x86_64-pc-linux-gnu_platform_gui` cache check ran on x86_64; its depends job built `platform_cxx` from the pinned archives. `linux64-build` staged that depends (`DEP_OPTS: PLATFORM_GUI=1`), configured with `platform gui = yes`, and ran `check-stdlib-paths` and `check-no-rust.py`. `linux64-test` passed. The sources cache had an exact hit, so its download step did not run in this run; run 41517453011 below exercised it.

  Not exercised: a pull request based before this one running develop's workflows after this merges. Its cache check now runs on x86_64, which is reasoned from `00_setup_env.sh` and `build-depends.yml`, not observed.

  Before that rebase, at this pin (`fb463c28`), on develop `92f2bfbc9ddb`:
  - Linux x86_64, in an `ubuntu:noble` container with gcc-11 and the `linux64_sqlite` configure flags plus `--enable-werror`, with the stacked PRs #7763, #7670, #7671 and #7765–#7767 applied on top:
    - `make -C depends PLATFORM_GUI=1` builds every package, including `platform_cxx` from the two archives.
    - `dash-qt`, `test_dash` and `test_dash-qt` build.
    - `check-no-rust.py` passes for `dashd`, `dash-cli`, `dash-tx`, `dash-util`, `dash-wallet`, `bench_dash` and the fuzz binary.
    - `make check` passes, and so does `test_dash-qt` with `QT_QPA_PLATFORM=minimal`.
  - macOS: two runs of `contrib/devtools/platform-bundle.sh` into separate `SOURCES_PATH`s produced byte-identical bundles and tarballs, with the hashes above.
  - Fork `push` run [41517453011](https://github.com/PastaPastaPasta/dash/actions/runs/41517453011) at 42c8e10 passed, with the `linux64_sqlite` CI design this PR had then.

  At the previous pin (`dc4dc8e8`), on macOS 27 (aarch64-apple-darwin, Xcode 27 SDK), unless stated:
  - `make -C depends PLATFORM_GUI=1` builds every package, including `platform_cxx` from the two archives. rustc reports `-lc++ -framework Security -framework CoreFoundation -liconv -lSystem -lc -lm`, and the system-library check and the forbidden-crate check pass.
  - `pkg-config --static --cflags --libs dash_sdk_cxx` from the depends prefix gives `-I<prefix>/lib/pkgconfig/../../include -L<prefix>/lib/pkgconfig/../../lib -ldash_sdk_cxx -framework Security -framework CoreFoundation`.
  - `configure --enable-platform-gui` finds `dash-sdk-cxx` through pkg-config, and its link test passes. Without the `.pc` file configure stops and says to build depends with `PLATFORM_GUI=1`. With `PLATFORM_CXX_LIBS=-ldash_sdk_cxx`, which drops the vetted frameworks, the link test fails on the missing framework symbols.
  - Without `PLATFORM_GUI=1`, `make -C depends print-packages print-native_packages print-all_packages` gives the same result as develop for the native host and for x86_64 Linux, armhf, aarch64 Linux, riscv64, ppc64, mingw-w64, x86_64 macOS and arm64 macOS. With `GUIX_ENVIRONMENT` set, `PLATFORM_GUI=1` stops with the Guix error, and a default build does not.
  - Two runs of `contrib/devtools/platform-bundle.sh` into separate `SOURCES_PATH`s produced byte-identical bundles and tarballs. depends fetched the tarball from GitHub again during the build, and it matched the pin.
  - Lints: lint-shell, lint-shell-locale, lint-whitespace, lint-files and lint-python-utf8-encoding pass. actionlint reports nothing new in the touched workflows compared with develop.

  Not run at this pin: the macOS and mingw-w64 `platform_cxx` builds. Not run at all: Guix, or a build on armhf, ppc64 or riscv64.

  ## Breaking Changes

  None. Without `PLATFORM_GUI=1` and `--enable-platform-gui`, depends and configure behave as before.

  ## Checklist:
  - [x] I have performed a self-review of my own code
  - [x] I have made corresponding changes to the documentation
  - [ ] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_

  🤖 Generated with [Claude Code](https://claude.com/claude-code)

Top commit has no ACKs.

Tree-SHA512: 17ddacb35004f89257eb8eb27d993d1dd79be2131d0ee4d01f10668974a17f10223b59edfdf9d51be985e1ecfbc0638568f254085435c962d3d00b25b3bb7d1a